IBIS Macromodel Task Group Meeting date: 04 December 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the only ATM meetings we expect to cancel in the next few weeks are those on December 25th and January 1st. The January 29th meeting will be cancelled because of DesignCon. ------------- Review of ARs: - Randy to investigate if/why/how a clock waveform input might be used. - In progress. Randy noted that internal discussions continue. - Michael M. to investigate if/why/how a clock waveform input might be used. - In progress. - Michael M. to check with IP experts on whether DC_Offset is useful for Tx. - In progress. - Walter to update the DC_Offset BIRD draft. - Done. Introduced as BIRD197 at the previous Friday's Open Forum meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the November 27 meeting. Mike L. moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: DC_Offset BIRD197: Arpad noted that BIRD197 had been introduced at the last Open Forum meeting, and that Bob had raised some editorial issues. Walter noted that he had begun a new draft incorporating Bob's changes. Bob noted one additional typo "SC_Offset" instead of DC_Offset. Bob also suggested that we carefully distinguish between the Definitions: and Usage Rules: sections. He noted that the sentence in the Definitions: section describing the EDA tool's responsibility should probably be in the Usage Rules: section. Walter removed the offending sentence from the Definitions: section. Radek suggested replacing "average" with "mean value" and Walter made the change. Bob noted some additional spacing and formatting issues, which Mike L. said the Editorial Task Group would address. Bob suggested the new draft be sent to ATM for further review as BIRD197.1 draft 1. Walter agreed and took the AR to send it out. DDR5 related topics: Arpad noted that Ted Mido's presentation to the Open Forum meeting had offered a few suggestions for handling some of the DDR5 challenges. Arpad asked if we might embrace some of those suggestions by turning them into BIRDs or if they would all be handled at the tool level? Walter noted that most substantive proposal was for a new parameter to indicate that clock_times would be used as an input to the Rx and would contain the times of the DQS transitions. Walter noted that people generally agree that this mechanism could be used to get clock ticks into the Rx. Walter said the questions remain: what do they mean to the .dll and the EDA tool, and who is responsible for generating them and determining the DQ to DQS skew? Walter noted that Ted also did not have a ready answer to the skew question. Walter noted that Fangyi had been leaning toward a component model. Walter thought the component model would control the DQS, and that the AMI Tx model could serve as the component model and output the clock ticks and control the DQ to DQS skew. Walter noted the presence of many interesting detail questions related to controlling DQS and the skew to one or more DQ lines. Arpad noted that we are currently waiting for more feedback from Randy and Michael M. to help define the problem. Walter agreed, and said we are waiting for someone to propose a way to generate DQS that we all agree solves the problem(s). He noted that the mechanism for implementing the passing of clock ticks (as mentioned above) is fairly straightforward. However, he noted that there had been some objection to earlier proposals to use the AMI_parameters_out argument in a bi-directional way, and this was similar. Radek noted that using clock_times as an input was less problematic because the EDA tool was already responsible for allocating the memory for clock_times. With AMI_parameters_out, the issue with proposing bi-directional usage was that the model was responsible for allocating the memory in the original output direction, and the EDA tool would have to allocate the memory for the input direction. Ambrish noted that delay between DQ and DQS could be determined by looking at the step responses. Walter agreed, but noted that the skew between them is changed by the controller during training. Walter noted that the model has to figure out the skew one way or another, and then there are impairments (jitter) for DQ vs. DQS. The AMI jitter parameters can deal with the impairments. Randy noted that Ted had some slides dedicated to correlated vs. uncorrelated jitter between strobe and data. Randy noted that one of the things they were investigating as part of the clock waveform AR was whether the existing AMI jitter parameters could adequately model the jitter in the system and avoid any double counting if you have jitter that is correlated between data and strobe. Walter noted that Ted had mentioned Sj, but Walter said he thought Sj went away because it's clock forwarded. Randy agreed that you might be able to track out certain parts of Sj but maybe not all of it. Arpad asked if it looked like we'd need new jitter parameters. Randy said that's what they were investigating, and so far the existing parameters were sufficient, but there might be some limitations to using them. Mike L. agreed that so far we hadn't yet seen any reason for an IBIS change, and he said that he thought what Ted was suggesting was largely for EDA vendors. He noted, however, that it would be good to work with Ted if we got to the point of a BIRD, because Ted has thought about the issues and has some examples and simulation results. Walter said that to know what the issues are and how to account for them all we probably need lab data. We need to correlate with lab data to fully vet any ideas, and right now no one can say when they'll have real hardware and lab data. C_comp modeling: Randy noted that the enhanced C_comp BIRD draft is in good condition and is generally updated to BIRD189 and the Si_location and Timing_location changes of BIRD191.2. Randy reviewed his most recent presentation on the topic (see ATM archives from June 5, 2018). slide 5: Enhanced C_comp model for traditional connections. This BIRD allows one to replace C_comp with a black box model using IBIS-ISS or Touchstone. In order to avoid breaking simulators, the [C Comp Corner] must be used and the values it provides are used by the EDA tools for their K(t) compensation. The new model can be connected to the pad node and the various reference nodes. slide 6: Series elements within a buffer. The extra nodes in this example allow for filtering or series resistance between the pad node and the input buffer location. You could probe at the input buffer after the C_comp model (the new Buffer_I terminal). Bob had suggested the possibility of having two different models, one for output mode and one for input mode. That's written into the BIRD, but one of the things we discussed before was whether we really wanted to allow a series element that creates the Buffer_O node. We discussed removing that option to simplify this BIRD and having model makers use BIRD189 to represent the on-die interconnect instead of putting that in this C_comp model. Walter noted that in the drawing the Pull_up and Pull_down curves seem to be shown in the upper triangle (I-V & K-T in drawing). When it's a receiver those are turned off. This picture implies the Power_Clamp and Gnd_Clamp curves apply to the input. We would need clarification to avoid confusion about how to implement this. Arpad asked about Submodels and where they would be applied in this figure. Randy clarified that when you have an Input you can use the I/V curves for Power_Clamp and Gnd_Clamp and any non-driving Submodels. The new Buffer_I node is just where the Input buffer sits, but everything is still there in terms of the normal Input [Model]. Arpad noted that he thought part of the reason for the series elements was to model a series impedance that existed for the Input path but was not in the Output path. Randy agreed. Arpad asked if the clamping diodes would be viewed through that series impedance or if they would be more effectively clamping at the driver triangle. Randy said this was a good point, and he noted that clamping (like ESD protection) typically exists very close to the pad. Arpad noted that for transistors the clamping often came from a parasitic diode between the substrate and the source or drain of the transistor. This might make it impossible to separate the clamping behavior from the driving I/V curves. So, the clamps should be kept in the driving triangle unless the clamps are a special separate ESD circuit. Randy noted that he's considering a change to remove the Buffer_O terminal from this option. This would mean we can't have any series element to separate the driving transistors from the pad, (the Buffer_O and pad collapse to one node) but that's reasonable because you could represent such a circuit using BIRD189 instead. Bob noted that Submodel is separate from this proposal and additive. Arpad noted that the question (for slide 6) was where it was to be added. Bob also noted that every driver has the Input model as a load. Referring back to slide 5, Bob noted that in reality the C_comp might be different in Input mode vs. driving mode. He noted that this is something IBIS currently doesn't support, and that he thought it would be a mistake not to address it with this improved C_comp proposal. If we are adding more complex C_comp models, we should address the fact that C_comp might differ for different modes. Bob also noted that the various reference nodes also connect to the buffer triangles themselves. Randy agreed and said that if it was confusing that these connections were not shown explicitly then he could consider changing the slide. Arpad asked when Randy hoped to get this into the spec. Randy said he would want it to be part of 7.1. Bob asked if it was a concern that this new C_comp could not be used with [External Model] (when [External Model] is used it overrides any regular [Model] constructs). Arpad and Radek noted that [External Model] with multi-lingual would allow the model maker to do anything they wanted. slide 7: Randy noted that we had previously discussed whether we wanted the additional complexity to support a C_comp model that tied together two pins from a [Diff Pin] pair. However, he noted that this might support true differential models with series elements, etc., between two buffers, but that this might break some EDA tool assumptions. Arpad noted that aside from true differential [External Model]s, IBIS wasn't very good at differential models. It's one thing to have pseudo differential independent buffers, but adding all the differential capacitance, etc., between them seemed a more important feature of this figure than series elements. Walter said he had the same question about this figure that he had noted earlier. Where are the I/V curves connected, given that Buffer_O_pos and Buffer_I_pos aren't the same node? Randy clarified that for this picture all I/V curves would be connected to Buffer_O_pos. Buffer_I_pos is simply a node you can probe to see filtering effects that would be present at the Input circuitry. Arpad suggested the drawing was incorrect because the Input looks like a true differential receiver (one buffer triangle), but the outputs are shown as two separate triangles. Randy said the [Diff_Pin] statement says the two pins are a differential pair, and you measure them with a differential voltage. Arpad acknowledged what Randy was trying to represent in the picture, but said he was afraid someone might misinterpret the drawing to mean the receiver was a true differential and the drivers were pseudo differential. Bob noted that IBIS traditionally has problems with true differential modeling because of single-ended test fixturing assumptions. If we added too many features and nodes to this BIRD, we might make model extraction physically impossible. Walter noted that at this point, with these new C_comp proposals, we would have to give up on the idea of using measured data in the IBIS file. The only way to generate some of these new C_comp models would be via simulation, where you can probe nodes you can't physically probe. Randy noted that he would give some more thought to cleaning up the BIRD and removing some of the complexity. - Mike L.: Motion to adjourn. - Walter: Second. - Arpad: Thank you all for joining. AR: Walter to send out BIRD197.1 draft 1. ------------- Next meeting: 11 December 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives